Looks good to me, thanks for this! Also agreed on the action taken with DataView, and we can always tweak it if necessary and breakage comes up.

I noticed that FrozenArray is not implemented in webidl crate and some API does not work. The same problem actually exists for other APIs, like Clipboard and Bluetooth.
In my understanding, FrozenArray is a immutable array in Javascript. Since the mutability is not completely reflected in web-sys / js-sys crates (as long as I guess - is it correct?), I feel just generating the same codes as Sequence sounds fine. (I guess unifying Sequence and FrozenArray in https://github.com/rustwasm/wasm-bindgen/blob/3c0c2b39a44a584fa9ed984c663a59d08561d179/crates/webidl/src/idl_type.rs#L601-L607 would work.)

Or, it might be also fine to intepret any type for which to_syn_type returns Err as JsValue in Rust although it partially spoils the advantage of the typed language.

What do you think?

Ah yeah makes sense! I think that's the JS type appearing there anyway so seems reasonable to just do the same thing as Sequence. Thanks for catching this!

OK, will do!
Also I am going to add tests for DataView and FrozenArray in webidl-tests.
I cannot find any test for Sequence and Promise so I will add them as well.

Is there any reason to ignore generics arguments of Sequence? It seems to be possible to append it. The compatibility for these APIs would be broken, though. In addition, Promise can be also typed.

Currently we don't have a great way to thread it through to the Rust definition right now and doing so would probably be a pretty large breaking change for web-sys as well. That being said it'd be better if we could do it so I'd love to have it on the docket for a future release. Was there anything else you wanted to do here before landing though?

That makes sense. Let me squash all commits before merging.

Thanks again!